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(54) Context controller having automatic entry to povyer saving mode and processor employing 
the same 



(57) A context controller tor managing multitasking 
in a processor and a method of operating tlie same. In 
one embodiment, the context controller includes: (1) 
foreground and background task controllers tinat allo- 
cate processor resources to active contexts' corre- 



sponding to foreground and background tasks, respec- 
tively, and (2) mode switching circuitry, coupled to the 
foreground and background task controllers, that places 
the processor in an idle state and a power saving mode 
when all of the contexts are inactive. 
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Description ■ 

T chnical Field Of The Invention ■ . 

[0001] The present invention is directed, in general : 
■to computer processors and, nnore specifically/to a con- ; 
text controller having automatic entry "to power saving 
mode and a processor employing the context controller 

Background Of The Invention : ' 

[0002] The processors in general-purpose comput- 
ers/as well as those used a's embedded controllers, are 
typically programmed to handle a plurality of tasks con- 
currently. A-subset of these tasks'must be performed in 
a timely manner in response to specific, exogenous 
events, while the remainder of these tasks can be per- 
formed without stringent, real-time constraints. To han- • 
die both sets of tasks using a single data path, these, 
processors require an efficient mechanism for respond- :' 
ing rapidly to exogenous events', while allowing non-real 
time processing to occur whenever no exogenous 
events are being handled. 

[0003] - The predominant mechanism for event re- 
sponse is program interruption, which was first used in 
the mid-1950s. For the past 40 years: the vast majority 
of processor architectures have included aprogram in- 
terruption facility that ' suspends the execution of a 
"background" task, and initiates the execution of a "fore- 
ground" task, upon occurrence of the exogenous event 
(s). Each prograni interruption, typically called an "inter- 
rupt," causes a reversible change to the execution state 
of the processor upon assertion (suitably 'synchronized 
' to the processor's instruction flow) of an appropriate 
event: 

[0004] The priority interrupt, developed in the late- 
1950s, Is a corhmon enhancement to a program inter- 
ruption facility, in a processor'supporting priority inter- 
rupts, discrete priorities are assigned, either statically or 
dynamically, to'a plui-allty of event (interr^upt -request)^ 
signals. Associated with each of these-* 'signals is a 
uniquely identifiable ' res ijltan restate for ^the- reversible 
change in execution state of the* processbr^Each occur- 

■ rence of b priority Interrupt selects the resultant state 
associated with the highest priority internupt request as- 
serted at-the'time when the interrupt stafe change is in- 
itiated.-^ ' ' ' ■ " ■■^ - 
[0005] The fundamental action'when performing a re- < 
versible change in the program execution*^ -state of a 
processor is to save the interrupted program's execution: 
address (and innplicit inter-instruction status, such as 
condition codes); and -to commence 'interrupt* process- 
ing at' a program 'address associated^ with the event 

'causing the' interruption.' This program address is gen- 
erally obtained from a predetermined memory location 
knowri'as arilnterrupt vector -At the end of the interrupt 

- handling routine, the saved execution address (and star, 
tus value; if any) are' restored, permitting execution of 



the interrupted program to resume at the point of inter- 
ruption. In most interrupt handling routines, jt is neces- 
sary to save,- and subsequently to restore, additional 
processor state to perform the operations necessary to 
5 - respond tothe interrupt. This additional state-is primarily 
• the contents of processor registers other than the pro- 
gram counter . - 
- ' [0006]' Saving^and restoring these registers to/from a 
stack or dedicated block of memory can consume con- 
10 siderable amounts of time. Therefore,- as integrated cir- 
; cuits began reducing the cost and size of hardware reg- 
isters in the mid-1960s, some, processors were 
equipped with multiple. sets of registers.- Selection of a 
different set of , registers, either by the interrupt support 
^5 hardware or by the interrupt handling software, allowed 
substantially faster interrupt.response by eliminating the 
. overhead of saving and restoring registers to/from main 
memory. ■ . ^ ,: 

- [0007] The multiple register set concept reached its 
20 nnodern form on the IBM System/7, introduced in 1970. 
The System/7 had a dedicated, hardvyare-selected reg- 
ister set for .each interrupt level,, and. reduced interrupt 
, context switching time still further by including in each 
set a register to save the execution address, (program 
25 ... counter value) when the level was preempted by an in- 
terrupt on a higher priority level. The. result was an in- 
.: terrupt context switch time of 800ns and an interrupt re- 
. turn time of 400ns, both of which were truly exceptional 
speeds for a 16-bit minicomputer built using 1969 tech- 
30 nology. The System/7 also pioneered dynamic interrupt 
■ assignment, where the priorityjevel used by each inter- 
' : rupt source was set by software, and could be changed 
during system operation. -. 
[0008] The ultimate generalization of this register set 
35 plus program counter technique was to allow events to 
in itiate handling routines at their last execution address, 
rather than requihng them always to start using an in- 
terrupt vector. address. For. controlling I/O devices, data 
. .communication and network protocols,. and other proc- 
40 , esses defined in terms of communicating state ma- 
' chines,- this was a major benefit;- because a state ma- 
chine could be implemented using the level's program 
counter both-for instruction addressing and as the (im- 
plicit) state register This not only eliminated -the need 
^5. for a separate state register but also- eliminated the 
, : overhead of a dispatch routine to select the appropriate 
. . handling: routine based on the value in the state register 
r. .: In effect, the register.set plus program counter architec- 
ture provides direct hardware support for the "task" or 
so "execution, ^thread" concepts commonly supported by 
operating system software. 

[0009] The first machine developed with the intent to 
implement I/O control state machines using this tech- 
nique was the "Alto" experimental personal, computer 
55 designed in 1 972 by Charles Thacker at the Xerox Palo 
Alto Research Center Since the early-1 970's many var- 
^iations of these interrupt and context switching mecha- 
. - nisms -have been developed for single-chip microcom- 
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puters and microprocessors,- However, none of these 
variations have introduced a Tundanneritaily new mech- 
anism for'rapid context switching in response-to exoge- 
nous events. ' ' • ' - ^ - • ; - • 
[0010] In high-performance systems it is often possi- 
ble to dedicate (one or more) processors for i/O control 
and/or external event handling. However if implement- 
ed with siniilar technoIogyMo that used -in the central 
pr6cessor(s) of the system? the utilization of -these I/O 
processors tends to be very low. This is due to the fact 
that/'for any particular circuit technology, the logic de- 
vices used to' implement processor data paths operate 
significantly faster than the storage devices used to im- 
plement main memory, and both the logic and memory-, 
devices can support higher data bandwidths than any 
of the attached peripherail devices. 
[0011]'" During the'O960s, the architects of high-per- . 
formance systems that required multiple I/O controllers 
developed a technique to. share a single data path 
among a plurality of controller functions; even though 
those- functions are logically -disjoint. The technique 
used a single physical data path and instruction decoder 
to -process,' on a round-robin basis, the instruction 
stream^s of a plurality of logical processors. The only 
'dedicated' resource for each togicai processor. was the 
storage to hold its execution state (program counter and 
register values). The control circuitry allowed execution 
'of a predetermined number of .instructions (generally 1 ) 
for=each logical-processor oh a sequential, cyclic basis..; 
This cohtPol circuitry changed which one of .the stored.- 
execution states was^ accessible to the data path be- 
tween the instruction cycles for different logical proces- 
sors. This technique was first used by Seymour Cray in 

• the "early 1960s to -implement 10 I/O controllers (called 
peripheral processors or "FPUs") using a single, shared 
data path on the Control Data Corporation (CDC) model 
6600: . ;. 

[0012] ^Note that this logical processor state switching 
occurred on a- strict time basis, and not in. response to 
■exteimal events.' Indeed, some successors :to the Gon- 
•trol Data 6600 PPUs implemented a pnonty interrupt 
■■ scheme on their logical processors. More recently this 
data path'sharihg technique has beenapplied to central 
processors, where it is called ''shared resource multi.- 
■ processing." In this case a plurality* of.Mndependent in-i 
struction -streams, 'from diff.erent CPU.- tasks or pro-- 
■grams, are interleaved to decrease pipeline dependen- 
cies, thereby' improving resource utilization: of a super- 
scalar data-= path.- 

[0013] Accordingly, what is needed in the art .is a way 
to configure, allocate and manage contexts .that has a 
more general flexibility. ' v :■ 

Summary Of The Invention ' ; 

[0014] To address the above-discussed deficiencies 

• of the prior art; the presentinvention provides a context 
controller for managing multitasking in a processor and 



a method of operating the same. In one embodiment, 
the context controller includes: (1 ) foreground and back- 
ground task controllers that allocate processor resourc- 
es to active contexts corresponding to foreground and 
s ...background tasks, respectively, and (2) mode switching 
circuitry, coupled to the foreground and background task 
controllers, that ptaces.the processor in an idle state and 
• a power saving mode when all of the contexts are inac- 
tive. 

10 [001 5] The present.Jnvention therefore introduces the 
broad concept of automatically entering a power saving 
mode when all ithe tasks that a processor can execute 
are inactive. With the advent- of processors, having a 
: hardware-based povyer- saving mode, early automatic 
entry into the noode yyithoutthe need for software to de- 
tect the opportunity to address the. -povyer savings can 
save significant.energy and can sirnplify the control soft- 
ware. 

[0016] • In one embodiment of the present invention, a 

20 software switch operation distinguishes the foreground 
• tasks from the background tasks. In an embodiment to 
be illustrated. and described, a software switch is con- 
tained within a task-programmable register associated 
with.each context. "Context," for purposes of.the present 

25 invention, is defined as, all processor state information 
(orany subset thereof, and such as register values) that 
would, be of use in restoring, the processor to a given 
state: The context controller detects the state (0 or 1 ) of 
the switch to determine whether the associated task is 

30 a foreground task or a background task. Of course, des- 
: ignation of foreground and background- tasks can be 
made in hardware, at the expense of flexibility 
[0017] In. one- embodiment of the present invention, 
the foreground and background task controllers allocate 

35 the processor resources only to the active contexts. In 
this embodiment, inactive -tasks are not allocated any 
f processor time to execute. Alternatively, inactive tasks 
.could, be allocated some minimal execution time with an 
attendent reduction in efficiency. 

40 ■ [0018], In one embodiment of the present invention, 
the-background task controller switches among the con- 
texts .corresponding tp:background tasks based on num- 
bers of instructions executed by each of the background 
■ tasks. This i.s referred to herein as "instruction slice." Ex- 

^5 ecution pf, background, conte.xts can alternatively be 
basedioatime ("time slice"). OfjCourse, other bases for 
cyclic activation are within the broad scope of the 
present invention. \r.y:-: 
^ [0019] In one embodiment of the present invention, 

50:_ . the states of .each context are stored in separate register 

. ) sets. I'Some. processor architectures support multiple 
. physical register sets, remapping logic.al, registers ther- 
*eon. as( tasks, are switched. Alternatively .portions of 
main memory may be taken-to store register contents 

55 in separate sets.- . . , .. ;■. ,r 

[0020] la one embodiment. of the .p.resent jnvention, 
- - the foreground task controller .that activates, contexts 
corresponding tp foreground tasks basedon. priority and 
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in response to events and the background task control- 
ler cyclicly executes- contexts corresponding to back- 
ground tasks subject to activation of the contexts corre- 
sponding to the foreground tasks. An "event" is defined 
as a stimulus capable of causing the context controller 5 , 
to respond by'switching from one foreground task to an-- 
other. Thus, 'tasks rriay be divided into foreground and 
background tasks and allocated processbrr resources : 
using substantially different criteria. Of course^ fore- 
ground tasks nnay also be handled oh a time slice basis,. . 1Q 
perhapS'ih' terms of instruction count; 
[0021] In one embodiment of the present invention,' • 
the foreground task controller is adapted to activate a- 
context corresponding to a particular foreground task by 
vectoring to a software^selectabld memory location. By 
aHowing the entry pbint of the' particular foreground task 
to vary, a state machine "can be established on which 
the initial execution address'for the. context activation 
also serves as the state indicator ^allowing the fore- 
ground task to execute as a' function of the event that 20 
brought about its execution. Of coursev the same state . 
machihe process can take place with respect to activa- 
tion of background tasks. ' 

[0022] The foregoing "has outlined, rather broadly, 
preferred and alternative features of the- present inven- 25 
tion so that those skilled in the art may better-understand 
the detailed description of the invention that follows. Ad- 
ditional features of the invention will be described here- 
inafter that form-the subject of the claims of the inven- . 
tion. Those skilled in the art should appreciate that they 30 
can readily use the disclosed conception and specific 
embodiment as'a basis for designing or modifying other . 
structures for carrying out the same purposes of the 
present invention'. Those iskilled in the art should also, 
realize that such^ equivalent-constructions "do not depart 25. 
from the spirit and scope of the invention in its broadest ■ 
form. ■ 

Brief Description Of The Drawings 

[0023]" "For a more connplete ■ understanding of the 
present invention, reference is now made to the follow- 
ing descriptions taken in conjunction with the-accompa- 
nying df-awings, in which: ' i'?r.; ■ 

FIGURE 1 -illustrates a state transition diagram 
• ' '■ showing operation of one embodiment of a proces- 
sor of the present invention from the^ point of view 
• of an individual context; . •■ 

- - FIGURE 2 illustrates a diagram exemplifying possi- 
ble proces'sihg flow, preemption/and inter-context 
communication 'on a processor operating with five 
- foreground 'contexts^ and three background con-' 
tex:ts: - . ^ 

'* FIGURE 3 illustrates exemiDlary per-context control 
and status registers accessible to software execut- 



ing in a processor employing an embodiment of the 
present invention: 

FIGURE 4 illustrates a system diagram of a typical 
processoror'l/O controller incorporating.anr embod- 
iment of the context controller of the present inven- 
tion:- , - , : ■ • • ■ . 

FIGURE 5 illustrates an interaction diagram show- 
ing an. internal structure of the;Context controller il- 
lustrated in FIGURE 4; . ; . ^ 

FIGURE 6 illustrates a process diagram of an event 
synchronization process illustrated in FIGURE 5: 

FIGURES 7A, 7B, 7G and 7D collectively. illustrate 
process diagrams of the event prioritization process 
illustrated in .FIGURE 5; 

FIGURE'S illustrates a tinning diagram for g context 
switch controlled by the present invention in which 
a current context's state is stored into, and the next 
context's state is loaded fronn, synchronous (self- 
timed) SRAM or register files;> ^ . 

FIGURE 9 illustrates a timing diagramifpr a context 
switch controlled by the: present invention where a 
current context's state is stored into, and. the next 
context's state is loaded from, asynchronous SRAM 
or register files; - ■ 

FIGURE 10 illustrates a schematic diagram of one 
embodiment of a circuit suitable for implementing 
event recording, event. masking and event acknowl- 
edgment for each activation event, as well as man- 
agement of a context activity bit, including initializa- 
tion request and watt, request logic: 



FIGURE 11 illustrates field and bit assignments of 
40, machine instructions pertaining to. context control 
and inter-context communication in the instruction 
set according to one, embodiment of the present in- 
..vention-; ■ > • > . 

45 -; , FIGURE -1 2 illustrates sources of bits used to gen- 
erate control store addresses on the processor ac- 
- ; cording ;to one embodiment of the present inven- 
tion; - : '. ; 

■so ^ ■ FIGURE 13 illustrates an exemplary data structure 
diagram for initialization vectors in control store ac- 
cording to one embodiment of the present inven- 
. tion; and ' < ^ 

•55 ' . FIGURE 14 illustrates a diagram setting forth target 
: address generation by vector instruction used to pri- 

.( • ' oritize and decode specific context, activation bits 
on the processor according to one.embodiment of 
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the present invention. ■ - ■ : ' 

Detailed D scription 

[0024] Referring initially to FIGURE 1 > illustrated is a 
state transition diagram showing operation of one em- 
bodinnent of a processor of the present^ invention from 
the point of view of an individual context. The present, 
invention provides a context controller for managing, 
multitasking in a processor that includes foreground and ' 
background task controllers that allocate processor re- 
sources to active contexts corresponding to foreground 
and background tasks, respectively^and mode switch- 
ing circuitry, coupled to the foreground and background 
task controllers, that places the processor in an idle 
state and a power saving mode when all^of the contexts: 
are' inactive. 

[0025] The present^invention therefore introduces the . 
broad concept of automatically entering a power saving 
mode; without the need for software to detect that such 

' entry is possible^ when all the tasks that a processor can 
execute are inactive. With the advent of processors hav- 
ing a -hardware-based power saving :mode, early auto- 
matic entry into-the mode can save significant energy. 
[0026] In one embodiment of the present invention, 
the foreground task controller activates contexts corre- 
sponding to foreground tasks based on\ priority and in 

'response to events and the" background task controller 
cycficly i switches among contexts corresponding to. 
background tasks subject to activation of the contexts 
corresponding to the foreground tasks. An "event" is de- 
fined as a stimulus capable of causing the context con- 
troller to respond by switching from one foreground task 
to another. Thus: tasks may be divided into foreground 
and background tasks and allocated processor resourc- 
es using substantially different criteria. Of course, fore- 
ground tasks may also be handled on a time slice basis,, 
perhaps in terms of instruction count. 
[0027] ' At any given time that the processor is operat- 
ing, each context ts in one of six states; which are-logi- 

'cally grouped into four sets as a two raws by two col^ 

'■ umns (2x2) matrix. The top or foreground row 10 con- 
tains three states: an Rf state 18, a Pf state 20 and a Wf 
state 22 (where each includes an "f" to indicate fore- 

'-'ground) used by foreground contextis..' The bottom or 
background row 12 contains three states: an Rb state 
24, a Qb state' 26 and a Wb state 28' (where each in- 
cludes a "b" to indicate background), used by back- 
ground contexts. The active column 1 4 contains the four 
states 18, 20, 24, 26 used by the active contexts, while 
the inactive column 16 contains the two states 22 and 
26 used by the inactive contexts, respectively. 
[0028] The foreground row 10 states may be further 
defiriedas Rf IB (running, foreground), Pf 20 (preempt- 
ed, foreground) and Wf- 22 (waiting, foreground). The 
background row. 12 states may be further defined as Rb 
24 (running, background), Qb 26 (queued, background) 
and Wb 23'(waiting, background). During each instruc- 



tion cycle, only one context may be "running" (executing 
an instruction on the processor), or.the processor alter- 
natively may: be idle. -If occupied, the running context is 
the sole.context in the foreground running state Rf. Or 
if the state Rf -18 is unoccupied, the running context is 
the sole context in the background running state Rb 24 
(if occupied).' In one embodiment of the present inven- 
tion/Jhe execution states of contexts are stored in sep- 
arate- register sets. Some pfocessor.architectures sup- 
port multiple physical register sets, remapping logical 
registers thereon as tasks are. switched.. -Alternatively, 
portions of main memory, may be taken to store register, 
contents in separate sets. ■ - 

[0029]^ ..Most context transitions are. allowed to take 
place within: either theJoreground row 10 or.the back- 
ground row ..T2, .because inter-row transitions are only 
needed fWhen a, context switches between foreground 
and background, operating tasks which may be. distin- 
guished by a:Softw,are switch operation. In one embod- 
iment of the present invention, a, software switch state 
distinguishes the foreground tasks from the background 
tasks.^ In an embodiment to. be illustrated and, described, 
a software switch is contained wUhin- a task-program- 
mable register associated vyith each conte^cti. "Context, 
" for purposes of the present invention as stated earlier 
is defined as all processpr.state information (or. any sub- 
set thereof; and such as register- values) that would be 
of use in restoring the. processor to a given state. The 
context controller detects the s;tate (a zero or a one) of 
the switch to. determine whether the associated task is 
a foreground task or a background task. Of course, des- 
ignation of- foreground and background tasks can be 
madejn hardware, at .the expense of flexibility. 
[0030] However, this.occurs less frequently than con- 
text activation, preemption and. waiting. Transitions from 
foreground to background may only occur when the run- 
ning foreground context Rf 18 executes a CLRFG 
("clear foreground") function 34, which results in a tran- 
sition from, -the foreground running-state Rf 18 to the 
background queued state Qb 26. Because there are no 
..relative priority di.stihctions . among baqkground con- 
texts, ;the position in-the. background queue.given to the 
context. executing the C.LF=?FG function 34 is arbitrary. 
[0031] A context executing a CLRFG function 34 is 
leaving foreground operation and advantageously relin- 
quishes control of the processor for a minimum of one 
: instruction .cycle (as does a context executing a WAIT 
function 32 or 42). If a lower priority foreground context 
is in the preempted state Pf 20, that lower priority fore- 
ground context runs next (via a HIGHEST PRIORITY 
'.transitipn.36).. ,!f the preempted state -Pf -20 is unoccu- 
pied, .a- preerripted context already ,in^ the background 
■ state Rb-..24 runs n^xt, unless the background state Rb 
,24i.s also ^unoccupied. J.n this casa, ,the context at the 
head of the background queue in: th.e background 
queued state Qb 26 runs next, via a TIME SLICE starts 
transition 44. In thejilustrated embodiment, this occurs 
after a single instruction cycle with the. processor idle, 
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since b'oth the foreground running 'state Rf '18 and the- ■ 
background running state Rb 24 are unoecupied. 
[0032] A 'transition between background and fore- 
ground normally occurs when. a context in background 
■running state Rb 24-executes a SETFG ("set fore- 
ground") function '30, which results in its transition fronn 
the backg'rouhd^unhihg state Rb;24 to the foreground 
running state Rf 18. Foreground activation of a particular. . 
context-nnay also occur by vectoring to a software-se- • 
lectab'le tbcatidn. ■ '^'^ - ' - 
[0033] tn one embddinnenf^of the present invention, 
the foreground task controller is adapted to activate a 
context corresponding to a partidular foreground task by ' 
vectoring to a software-selectable nnennory location. By. 
allowing the entry point of the particular foreground task 
to Vary, a state nnachine can be established, allowing 
the foreground task to execute as a function of the event 
that brought about its execution. 'Of course, the same 
state inachine process can take place with respect to 
activation of background tasks. ■ ■ . 

[0034] To prevent erroneous disruption of context op- 
eration; the functions available in the context controller 
' advantageous iy do not include a 'mechanism by which 
a running context can change the foreground or back- 
ground setting of any other context without also forcing 

■ an initialization (INIT) of that context. The INIT function 
may be executed by the running- context with any other : 
context as the target. An INIT function can be executed 
to the running context, but no reason exists to do so un- 
less a particular embodiment attached additional initial- 
ization side effects to the INIT function. Execution of an 
"INIT function leaves the target context in the foreground 
preempted state-Pt 20 with its program counter set to a 
predetermined initialization vector address,- as will be 

' discussed in greater detail below. 
[0035] Normally, the target of an INIT function resides 
in the foreground wait state Wf'22 and'enters the fore- 
ground preemipted state Pf 20 via a transition 40. Or it 
may reside in the background wait state 28 and en- 
ter theforeground preempted state Pf 20., switching from*, 
backgrdund to foreground via a transition 50. In fact, the 
transition 50 is also possibie'and equivalent, if the target 
context resides in either the background -r toning state 
Rb 24 or the background queued state^Qb'26, but FIG- 
URE 1 does not illustrate these two cases'. ' - 
[0036] At the end of a "processor reset, aH <:ontexts are 
in the foreground wait state Wf 22, exce^jt' the lowest-.' 

apriority content, which is in the foreground running state 

■ Rf 18.' Software "exeicuting on the context -foreground 
running state'Rf 1 8 may initiate a transition to the context- 
foreground waiting state 'Wf 22 'by executing a WAIT:- 

. function 32. A'foregrdund waiting state Wf -22 context 
transitions to the foreground preempted state Pf 20 with 

' an assertion of any of that context's activatidn events 

' that" are enabled by the con text's- 'event mask or- when 
the' running 'context executes' an I fslIT - function to this; 

' context foreground preempted 'state Pf -20 via' the tran- 
sition 40. * • ■ ' ' ' " • ' - • " 



[0037]' In the illustrated embodiment, a.preemption 
■ context switch may occurs at the end of every .instruction 
. cycle; with, the highest priority context ip the foreground 
. preempted state Pf 20, if any, entering the foreground 
:5 ...-running state Rf 1 8 via the HIGHEST PRIORITY transi- 
, . tion:36, .and the previous, context in the foreground run- 
ning state Rf 1 8, if any, entering the foreground preempt- 
. ed state Pf 20 via a HIGHER PRIORITY ACTIVE tran- 
sition 38. • 
.10 [0038] Software executing in the. context background 
running state Rb 24 rnay initiate a transition to the back- 
ground waiting state Wb 28 by executing a WAIT func- 
., tion 42. A context in the background waiting state Wb 
28 transitions to/the background queued; state Qb 26 
with the assertion of any of that context's activation 
; events .that are enabled by the , context's event mask. 
Transitions from the background queued-state Qb 26 to 
the background running- state Rb 24 may .only occur 
when .no foreground context is running (no context in 
20 state Rf 18). In this case, the running context if any, is 
in the background running. state Rb 24, or.the processor 
is in an idle state because no context is ready to run in 
either foreground or background. - 
. : [0039] At the end of every, instruction cycle,' with the 
25 context running in the. background state Rb 24, the time 
slice count is decremented, and on the instruction cycle 
when the count reaches zero, a time slice context switch 
preferably occurs. At this point, the context at, the head 
of the background queue enters the background running 
30 state Rb 24 via the transition-44, and the context previ- 
ously in the background running state Rb 24 enters the 

• background queued state Qb 26 via the transition 46. 
[0040] Generally, the background queued contexts 
are organized in a first-in, first-out (FIFO) arrangement 

35 with "wrap-around" occurring from.the highest context 
number to the lowest context number when a previous- 
ly-running background context enters the background 
queued state Qb 26. It should be, noted that foreground 
preemption involves a state transition via. the transition 

40 36, whereas background preemption by foreground 

• does not. In this case, the previously-running back- 
ground context remains- in the state Rb 24 until the fore- 
ground running state Rf 18 is again unoccupied and a 

'~' background context- is able to run. 
45 [0041]-; Turning now to FIGURE 2, illustrated is a dia- 
gram exemplifying. possible processing flow, preemp- 
tion and inter-context communication on a processor 
operating. with, five foreground contexts and. three back- 
*! ground contexts? In one embodiment of the present in- 
50 ■ vention. the foreground and background task controllers 
. ■■ allocate the processor resources only to the active con- 
r= texts; In this embodiment, inactive tasks are not allocat- 
; ' ed any processor time to execute. Alternatively, inactive 
tasks could be allocated some minimal execution time. 
55 [0042] A context may be activated by the. assertion of 
an event signal. Associated with each context may be 
zero or more exogenous event signals and zero or more 
endogenous event signals The principal difference be- 
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tween exogenous and endogenous event signals is that- 
exogenous signals are'advantageously synchronized to 
the processor's clock before'betng used for context ac- 
tivation decisions within the context controiler. In con- 
trast, endogenous signals are assumed to be generated 
-in synchronism with the' processor's clock and are used 
'directly. • - . - ■ .^ 

[0043] ' Each^of the context's activation events may be 
enabled and disabled under software control by setting . 
and clearing bits in a context-specific event. mask reg- 
ister In-addition'to assertion of activation events due to : 
the assertion of hardware signals from exogenous 
sources, such as external interfaces, or from endog- 
"enous sources, such as interval timers. coprocessors or 
data transfer logic, some or alhevents may be asserted 
by software usirig signal instructions that specify a target . 
context number 'and event number within the set of 
events associated with the target context. Since any 
context can signal events to itself or to other contexts, 
this allows the illustrated embodiment to serve as an ef- 
ficient^mechanism for both, intra-context and inter-con- 
text communication as well as serving as a priority in- 
terrupt controller and as a time slice controller. 
[0044] In one embodiment of the present-invention, 
the background task- controller activates the contexts- 
corresponding to 'background tasks based on' numbers 
of instructions ' executed by each of the background 
■tasks. This is referred to herein as "instruction slice." Ac- 
tivation of contexts can alternatively be based on time 

- ("time slice"). Of course, other bases for cyclic activation 
are within the broad scope of the present invention. 
[0045] " In the diagram of FIGURE 2, theTvertical axis 
represents contexts, while the horizontal 'axis repre- 
sents context activities for each of the eight contexts 
supported on the exemplary context controller. The hor- 
izontal axis is time; in units of instruction execution cy- 
cles. The wide btackOines, for foreground contexts, and 

- the' wide cross-hatched tines, for background contexts; 
show the running context. Vertical lines:-with arrows 
show the context switches and are labeled to identify 
the reason that a context switch: occurred. The small, 
perpendicular lines crossing the wide, lines indicate inr . 
structioh cycles. The numbers ..above, each, instruction - 
cycle interval for background.contexts. is the value of the 
time slice instruction counter when that ihstruc-tion is be- 

- ing executed. The narrow dashed black lines, for fore- 
ground contexts, and narrow ccoss-hatched dashed- 
lines, for background contexts, show active preempted 
contexts. Narrow dotted lines.. show active, queued ■ 
background contexts. This embodiment has eight-con- . 
texts, designated context'O (the highest-priority) through 

^ context 7 (the lowest priority.),- and^du ring this example.- 
is-operating with a time slice instruction count of eight.,, 
[0046] At the time this example starts, .contexts 0, 2, 
4 and 5 are all- inactive, foreground contexts Estate Wf). -. 
Contexts' 3, 6 jand 7 are all^ background contexts with . 
context 3 inactive (state Wb), context- 7 queued (state 
Qb) and context 6 running (state Rb). 
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■ [0047] . Context 1 is inactive,, and has an unknown (or 
indeterminate) foreground/background setting. A first 
instruction cycle 46. shown: is* executed by background 
context 6 as its time slice count value decrements to two. 
5 In a next instruction cycle 47, -background context 6 ex- 
ecutes a SIGNAL function to background context 3. As 
a result, background context 3 becomes active, entering 
I state.Qbonthe following instruction cycle. After sending 
the' .SIGNAL .function, background context. 6 executes 
10 another instruction cycle 48 as its time slice count dec- 
^ rements to 0. This causes a context switclTi.,to the next 
-highest context nurnber in. the active context back- 
ground queued. stat_e.Qb, which is background context 
7...Context6 enters the Qb, state and context 7 enters 
15 - the Rb state-at an instruction cycJe^SO with a time slice 
' . count^value of 7. After.context 7 has executed three in- 
structions, an ^exogenous event activates foreground 
context 4. Therefore, at the end of a next instruction cy- 
cle 52; background context 7 is preempted by fore- 
go ground context 4 with its time slice count value remain- 
ing at four during- the preemption. ■ I.' 
. [0048] Foreground context 4. executes its first instruc- 
-. tion while an exogenous event activates fpreground 
= context 2. Therefore, at the end of a next instruction cy- 
25 ' . cie 54r foreground context 4 is preempted by foreground 
context 2. (at a preemption point 53) entering the 
preempted state Pf while foreground context 2 enters 
. the running state Rf. After executing two instructions to 
handle its activation event, foregrourid context 2 exe- 
30 . cutes a WAIT function during a third instruction cycle 56. 
, This WAIT function clears the activity flip-flop for fore- 
. ground context .2, and after one more instruction cycle, 
foreground context 2 becomes inactive reverting to the 
, waiting state Wf. This allows the preempted foreground 
35 context 4 to return to the running state Rf and execute 
another instruction cycle 58. Because foreground con- 
text 4' had already executed its own WAIT.f unction prior 
to the preemption point 53, this is the final instruction 
V , executedby foreground context 4 before reverting to the 
-^0 ...waiting'state Wf and permitting preempted background 
context 7; to resume running at an instruction, cycle 60. 
, : ' • After executing four more instructions, background con- 
. text 7- completes its time slice 62,. resulting. in a context 
s.yyjtch .to the next.tpp Qb^context which is background 
45 context 3 because of a NA/rap-around of context numbers 
. .from context 7 to context 0. , ^ ; 
; [0049]-. During the same instruction cycle 64, the back- 
, gr.QundiContext 3 executes the first- instruction of its time 
■ . slice. 7, an exogenous event 66. activates foreground 
■50 .-.context 0, Therefore, at the end .of this instruction cycle 
; . 34, background context 3 is preempted by f9reground 
■ pontex.t 0, with. its time slice-coijnt value remaining at sev- 
, en during tfne preemption.- After exec.uting,three instruc- 
^tions to handle its ac.tivatiqn event, foregrpund context 
55- 0 executes a WAIT function during a fourt)i Jnstruction 
■ cycle 69.. This, WAIT fLipctioR clears .the.activity flip-flop 
for foreground context 0, and.after one rnore instruction 
cycle foreground context 0 becomes inactive, reverting 



7 



4 



13 

to the ' waiting state" Wf. This norrnal'ly allows the 
preempted background context 3 to resume running, but 
in this example an exogenous event SS-has activated 
(oreground context 5 while foreground context 0 was 
running. Note that this activation- changed the state of 
foreground context 5 from the waiting state Wf to the 
preempted state Pf. 'showing how-it is'possible for a fore- ' 
ground context to enter preempted state without having 
executed any instructions since activation. 
[0050] If backgroun'd cohtext 3 had been operating in 
foreground, the fact that foreground context 5 was in the . 
preemf3ted state Pf when foreground context 0 reverted 
to the waiting state Wf would be irrelevant, since back- 
ground context '3 is higher in priority than foreground 
context 5, However context 3 is operating in back- 
ground, so a WAIT function'69 executed by foreground 
context 0 results in a context switch to foreground con- 
text 5 which enters the" running state Rf and begins ex- 
ecuting an instruction 70 while background context 3 re- 
mains preempted in state Rb. 

[0051] After executing two instructions to handle its 
activ/ation event, foreground context 5 executes a WAIT 
function during a third instruction' cycle;7.1 . This WAIT 
function clears the activity flip-flop f or foreground con- 
text S/ and, after one more instruction cycle, context. 5 
becomes inactive and reverts to the waiting state Wf. 
Since no other foreground contexts 'are active at this 
time, preempted background context 3 resumes running 
in state Rb and executes the second' instruction of its 
time slice 72. On the next instruction cycle, background 
context 3 executes a WAIT function 73. The WAIT func- 
tion 73 clears the activity flip-flop for background context 
3, and after one nnore instruction cycle, background con- 
text 3 becomes inactive, reverting to the waiting state 
Wb. This allows queued background context 6 to return 
to the running state Rb at an instruction cycle 74. Note 
thai even though this context 'switch was not initiated 
by the time slice count decrementing to zero, back- 
ground context 6 enters the running state Rb at the in- 
struction cycle 74 with -a full time slice count value of 
seven, rather than inheriting the partial time slice re- 
maining when the background context 3 executed the 
WAIT function 73. " " ■■■ ' 

[0052] As its second instruction, the background con- 
text 6 executes an-INIT function 76 to' the foreground 
context 1 to force the foreground conte)ct'^<-into a known 
state as may be necessary to recover from a software 
error in the code executed by context =1 This I NIT func- 
tion activates context 1 as a foreground context 
preempted state'Pf 'with execution set to begin at the 
context 1 initialization vector address In control store.. 
BecausiB'an active foreground context now exists, back- 
ground context 6 is preempted (at' a preemption point 
77) by a context switch to context 1 after execution of 
'ohe more in'st ruction." As itS' second instruction, -context 
1 executes a CLRFG (diear foreground bit) function 78 
which causes context 1 to enter the background queued' 
istate Qb. Because' context 1 1s now on the background 
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■ queueand there isalreadyacontext in state^Rb. context 
. 1 relinquishes -control of the processor (at a relinquish 
, point-80) afterthe instruction cycle following the execu- 
tion of the CLRFG function 78. thereby allowing context 
. 5, 6:A0 state Rb to resume, executing the remainder of its 
: time slice 82... , ■ , - ' .. . ; , 

.[0053] ■In .the remainder of this Detailed Description, 
. ' numeric.constants are in decimal unless preceded by 
,"Ox" in which case they are in hexadecimal, and bit po- 
.10. sitions are p.umbered, with bit zero being the least-sig- 
. nificant ,bit..., . : - . 

[0054] Turning r:iow to FIGURE. 3, illustrated are ex- 
emplary .per-context control and status registers acces- 
sible to software executing in a processor employing an 
is embodiment of the ^present invesntiori.. Nine control bits 
per context 84 have values that are determined by soft- 
ware; and nine status bits per context 86 have values 
that are determined by context controller hardware, but 
whose values may be read or tested in pther manners 
20 . by. software. The context controllerfmaintams a portion 
^ of the state of each context. These s^tate bit^ are not part 
of the execution state (which is saved and restored dur- 
ing context- switching) because- the, context-specific 
state within, the context controller .is required continu- 
es : ously for use by activation logic-and also as inputs to the 

• context switching decision logic. , , 
[0055]., The ,per-cpntext control bits 84 include a fore- 

• . ground (FG) bit 88, arid an event mask register 90. The 

FG bit 88 is equal ;to one when the pontext is in fore- 
go ground. The FG bit 88 is illustrated as being set by hard- 
ware reset execution of the I NIT function with this con- 
: text as the specified target, or execution of the SETFG 
function while this context is running. The FG bit 88 is 
illustrated as being cleared by execution of the CLRFG 
. 35 function while this, context is running.. The event mask 
register 90 has a bit corresponding to each of the acti- 
vation events associated with the context. 
[0056] In the illustrated embodiment, each context is 
allotted eight activation events: the event mask register 
40 90 therefore contains eight bits. A given activation event 
. \ can only activate a context when the corresponding bit 
position nurriber which is equalto the event number has 
a value of one in the context event mask register 90. 
However, as.-will be explained in greater detail below, 
45 the' assertion, of an activation event, is recorded in an 

- event flip-flop which remains set until execution of an 
ACKNOWLEDGE (ACK) function for the specified bit. 

'( Setting of the event flip-flop is unaffected by the contents 
of the event mask register 90.. . . 

50 [0057] The per-context status bits 86 include an ACT 
bit 92.and-an event status register 94.. The ACT bit 92 
is equal to one when the context is active. The ACT bit 
92 is set by either an assertion of a non-masked activa- 

- tipn event, a setting of the event mask bit for an asserted 
55 unacknowledged actiyation event or an execution of the 

INIT function with this context as the specified target. 
• . . The ACT bit 92 is cleared by hardvvare reset (except for 
context 7: where the ACT bit is set by hardware reset). 
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and by execution of the WAIT function while the context 
is running. The event status register'94 has a bit corre-' 
sponding to each of- the activation e\yents - associated' 

■ with the context. These bits are also referred to as event 
flip-flops in some portions of this Detailed Description. 
[0058] As stated above, in the illustrated ennbodiment= 
each context i^ al lotted eight activation events' dictating 
that the event status register 94 contains at-least eight 
bits. The bits'corresponding tb asserted events read are 
equal to-one, and the bits corresponding to unasserted 
events read, including acknowledged events, are equal 
■to zero: individual event status register bits.'(event flip- 
flops) are set by context controller hardware upon de- . 
tection of assertion (typically a zero-to-one transition) of 
an exogenous or endogenous event signal The individ- 
ual event status bits may also be set upon execution of' 
a SIGNAL function specifying as a destination the sub- ■ 

' ject event in this context. Individual event status register 
bits are cleared by hardware reset and by executing an 
ACK function with the subject event as the specified tar- 
get, while this i::ohtext is running. In- some cases, a par- 
ticular ACK function may also be generated- as a side- 

• effect of executing other instructions or accessing par- 
ticular data path (typically I/O port) registers.' 

-^[0059] ' Ah' impiementatioh -example which illustrates 
context definition and usa'ge for ah IEEE 802.11 Media 
■Access' Control (MAC) controller is presented below. 
The functions of a MAC controller have been divided into 
eight contexts, designated 0 to" 7, with 0 being the high- 
est priority: Contexts 0 to 5 are preferably foreground ■ 

' and 6 and 7 are preferably background. Each context 

• has eight activation events- and each of the: activation 
events generally apply the following defaults: 

A. an event may not be asserted using the SIGNAL 
function, (ijniess the event is reserved for such pur- ■ 
'pose);" . ^ : 

' B.-an event is cleared using the ACK function: 

" C. timer terminal count events occur when the corr 
' - responding tihner decrements to zero: 

■ ' * D. timer terminal courit events are cleared by writing 

' to the 'corresponding tirher's cohtrol register with. 
' -■ 'Cleai^TC(bit2) equal to one,- not the ACK function; ..^ 

F: "assertion" of an external -event signal is defined 
as a 0 to 1 transition; m 

G. "negation" of an external'event'signal means a. 
r to 0 transition; and . ■ ' 

• H. control' bit names are chosen to be meaningful 
when the bit is equal to one. ■ > 

■ [0060] The exemplary contexts and their correspond- 
ing activatioh events are described below.'- 



. CONTEXT.O - Debug .support (and high-priority, real- 
time events): • , . . 
[0061} ^ Activation Events: 

:5, 0)- hardware breakpoint (BKPTin): 

1 ) software breakpoint (signal 0, 1 ): , 

2) GP serial shift corripiete or UART transmitter 
10 . done (GPDN/UTXD.N); 

3) interval timer A terminal count (INTATC); 

•4) UART receiver done (URXDN); ^ .'. 
15 , , - . - , 

5). interval timer B count (INTBTC); 

'6). host (computer system.) attention (HATN); and 

20 7) coprocessor attention (CPATN). 

Context 1 - Lower MAC. (LMAC) Exception Handling 
[0062] Activation Events: , ; - 

25 > . 0), modem data interface attention (MD.I ATN); 

1 ) physical layer data not available(!PDA); 

2) IFS (inter-frame space) timer terminal count (IF- 
■,30 STC); 

3) inter-context communication , from MMAC to 
LMAC; 

. 35 4) physical layer transmitter not ready (!TXR); 

5) beacon/dwell timer comparator equal (BCNTC); 

,.6) modem data interface programmable bit bound- 
40 ary (MDIBIT): and 

U • 7) modem management interface transfer complete 
(MMIDN). 

. • 45 -..-Context 2 - Lower, MAC (LMAC) Data Transfers: 
[0063] . Activation Events: 

, '0). modem data interface attention (MDI^TN); 

50;: . ^. 1 ) interval timer B terminal count (INTBTC); 

' " . - .2.) IPS: (inter-frame space) timer terminal count (I F- 
- -SJC); - ,: , ' : .■ 

. 55 ; I, 3):,, inter-context connmMnication^,f.rom . MM AC to 
. • -.LMAG (signal- 2,3);; v v:; ' - o '"^ :":.. •■ i . 

:4)TSFT (the synchronization function, timer) wrap- 
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around (TSFWRP): - 

5) NAV (network allocation, vector) timer terminal • 
count (INTCTC): ■ 

6) physical layer medium busy (MBUSY); and 

' 7) physical layer medium not busy (IMBUSY). 

Context 3 - Host Interface Support: , .. 
[0064] ■ Activation Events: 

0) -buffer access * path 0- offset resolution 
^(BUFATNO): ' - ' 

i -l)*- • buffer access path .1 offset resolution - 
(BUFATN1); 

- 2) inter-context communication for status reporting 
to host (signal 3,2); 

■ 3)^ buffer access path 0- block boundary crossing 
"• ' '(BLKATNO); > • " 

4) buffer access path 1 block boundary crossing 
(BLKATN1)- • 

5) inter-context communication for status reporting 
. ^ -to host: (signal 3.^5); ^ . ' . 

• 6) host interface register attention (HATN): and 

7) inter-context communication from background 
(signal 3,7). 

Content 4 - Middle MAC (MMAC) Medium Access and 

Timing: • - 

[0065] Activation Events: 

0) inter-context communication from:- LMAC or 
■ ' HMAC (signal 4,0); : . 

1) previously^busy * medium becomes . available • 
(MAVL); ■ ^ • : ■ - --^ ■ 

2) IFS/slot timer terminal count (IFSTC);.* 
''3) interval timer A terminal count (INTAXC); 

^ ' 4) beacon/dwell timer comparator (BCNTC); 
5)-modem" data interface attention '(MDIATN); 

- • 6) software flags 3-0 (shared with. context 7, event 

' 7);*and'-'' - • ' .•■■:■.-'.-* ■ 

7) modem management- interface transfer complete 
• ' (MMIDI).- ^ '■ . ■ 
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Contexts -WEP (wired equivalent privacy) Decryption 
Support: 
.[0066] Activation Events:. 

5 0) inter-context communication for status reporting 

-.. . ' (signal 5,0); . ■ • 

1) decryption keystream values ready (DECRYPT); 

10 y ■ 2) GP :serial shift complete or UART transmitter 
.done (GPDN/UTXDN); 

3) inter-context communication (signal 5,3); 

15 4) UART receiver transfer done (URXDN); 

5) inter-context corrimunication (signal -5,5); 

6) interval timer D termirial-count (INTDTC); and 
20 . , . - - . 

7) modem management irit erf ace, transfer complete 
(MMIDN). . . , . . 

Context 6 - Additional Access Point Functions: 
25 [0067] Activation Events: 

Oy software Jlags.11-8i . < - . 

1 ) software flags 15-1 2; ■ - : 
30 . . ■ . , - I . .. 

2) . GP serial . shift'complete -or UART transmitter 
done (GPDN/UTXDN); ■ - 

3) 'interval.tirner A terminal count (INTATC); 
35 ' : ■ : ■ . 

4) software flags 7-4; 

. 5) interval timer. B terminal count (INTBTC); 

40 , ^ -6) interval timer D terminal.count (INTDTC); and 

7) coprocessor ^attention- (CPATN). - 

Context 7 Upper MAC (UMAC) and ^Miscellaneous 
■45 Support:.. • ^ ■ 

[0068] = -.Activation Events: . ^. . 

■:0) software flags 19-16; : • - 

• 50 1 ).software flags 23-20; 

.• 2) software; flags 27-24; 

3) interval timer A terminal count (INTATC); 

£5 • 

4) beacon/dwell timer comparator'(BCNTC): 

5) interval timer B terminal count (INTBTC); 
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- 6) interval timer D terminat countXINTDTC): and 

7) software flags 3-0 (shared with context' 4. event 
6). 

[0069] Turning now to FIGURE 4, illustrated is a sys- 
tem diagram of a typical processor or I/O controller in- 
corporating -an embodiment of the context controller of 
the present invention. This diagram (as well as those 
illustrated in FIGURES 5, 6 and 7) is presented using 
the well-known graphical syntax of the Specification and 
Description Language (SDL) as standardized by the In- 
tern'ational Telecommunication Union- in ITU-T Recom- • 
mendation Z.100 (03/93). 

[0070] - The system behavior is presented using this 
formal description language because more precision 
and' broader general applicability- are achievable. For 
example, a schematic fragment could be used to high- 
light imple'mentation characteristics^ of the illustrated 
embodiment. However since this context controller is 
■applicable to almost any type of processor the schemat- 
ic for a particular processor is likely to omit aspects of 
the control sequences which are implicit for that proc- 
essor but may be relevant to^another processor using a 
different architecture. Also, a- conventional state dia- 
gram is a more informal notation having a similar objec- 
tive to the SDL process diagram. SDL has a rigorously 
defined graphical syntax, however achieving much less 
ambiguity. Indeed, it has been found that many "bound- 
ary conditions" in the behavior of this controller are not 
adequately' explained by conventional state diagrams. 
Examples of these boundary conditions, all of which are 
covered by the SDL description herein, include: (1) 
What 'happens if a context is preempted between exe- 
cution of a WAIT function and execution of the instruc- 
tion following the WAIT function? (2) What happens if a 
context executes the ACK function for the event which 
caused its activation during the instruction after execut- 
ing a WAIT function? and (3) If a background context's 
time slice ends on the same instruction cycle as it exe.- 
cutes a SETFG function, does that context continues 
running in foreground or does th^ next context in state 
Qb execute one instruction before being preempted by. 
the'new foreground context? "Also, SDL is able to de- 
scribe the behavior of the context controller 'with more 
precision and less ambiguity than is possible -using Eng- 
lish prose. Therefore, the SDL descriptions presented 
in the following paragraphs' are- intended to serve as 
both a general and a detailed guide to the structure and 
intended purpose of the sigrlificant features of several 
embodiments of this invention. 

[0071] An SDL system' diagram 100 shows the rele- 
vant top-level functional blocks of the processor used in 
the illustrated embbdimerftv Text' symbols 102 and 104 
contain the definitions of the system-specific extensions 
'to SDL's- predefined "data types? declarations of the re- 
mote variables used for implicit inter-block communica- 
tion via the export/import mechanisrin and declarations 
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of the names and parameter types of. the signals used 
for explicit inter-block communication. The system dia- 
gram 100 shown comprises five functional blocks: a 
clock generator 1 06, a sequencer 1 08, ao instruction de- 

5 coder 1 1 2, a data path and interface resources manager 
.114 and a context controller 110. 
[0072] The clock generator 106 accepts an input 
clock, or timebase reference (e.g., crystal-controlled 
signal) from which is generated a clock, via Clocks In 

TO channel 122 and a hardware reset signal via Resetln 
channel 1 20. The clock generator 1 06 generates the cy- 
cle clocks used by all other blocks. These cycle clocks 
subdivide the instruction cycle into, four substantially 
equal portions. This is done using a pair of square waves 

15 in quadrature, resulting in four clock edges at which to 
initiate various actions. Actual clock waveforms are il- 
lustrated in FIGURES 8 and 9, with^a master clock 
MOLK signal 504 delimiting the instruction cycle bound- 
. aries and a quadrature-dock QCLK signal 506 providing 

20 additional clock edges within each instruction cycle. The 
four edges, in sequential order are: a rising edge of the 
MCLK signal 504, designated Mr 517, which marks the 
end of one instruction cycle and the.^beginning of the 
next instruction cycle, a rising edge of the QCLK signal 
. 25. 506, designated Qr 518, which occurs 25% of the way 
through each instruction cycle, a. falling edge of the 
MCLK signal 504, designated Mf 51 9, which occurs 50% 
of'the way through each- instruction cycle, and a falling 
edge of the QCLK signal-SOS, designated Qf 520, which 

30 occurs 75% of the way through each instruction cycle. 
[0073] In the SDL ; model, the clock generator 106 
sends appropriate Mr 517, Qr 518, Mf 519 or Qf 520 
signals, as well as a reset signal, to all other functional 
blocks. The clock generator 106 operates while the 

35 processor is either running or idle, but can shut down 

■ • most of its circuitry, including.- the generation of the 
MCLK signal 504 and the QCLK signal 506, during a 
very-low-power sleep mode, which is entered when the 
clock generator 106 receives a sleep signal from the 

40 context controller 110 via channel ClkCctl 140. 

[0074] In many implementatioris, it is not possible to 
execute an instruction during every clock cycle. As a re- 
suit, -the instruction decoder 112, sequencer 108 and 
context controller 1 1 0 only perform their functions during 

45 the cycle when the instruction is actually being execut- 
ed," as; identified by, the rerriote Boolean variable "ien" 
being true (see text symbols 102). 
[0075]: The sequericer 108 generates instruction ad- 
dresses and initiates instruction fetch cycles via a ToCS 

50 .jcharvnel ;11 6. These. addresses connect to a control 
store array 117 logically external to the processor 100. 
' Note.that; depending on theinnple mentation technology 
and desired performance level, the control store array 
. :l17^andan.associated data.storeJ.27 nriay be physically 

55 separate, fully co-located in a single rriepnory device, or 
any hybrid thereof. The sequencer 1 08 receives context 

- switching signals GsLo^d (to. retrieve saved context 
state information), CsStore (to save context state infor- 



11 



# 

21 ^ r. ^ EP: 0 942 368 A2 22 



"mation) and lnitSeq'(td set a context execution address ■ 
to* the- appropriate tnitia^ization vector)- from the context 
controller 110 via CctlSeq channel 141 . . ■ " 
[0076] ■■ The instruction decoder 11 2. receives the in- 
struction' words fetched' "under control'of the sequencer 
108 via a FromCS channel 11B.. Decoded instructions 
are sent as signals, with the instruction field values as 
parameters^ to all other blocks as appropriate. The in- 
structions requiring processing in the context controller 
110 are sent via an InstCctI channel 142. • . ~ 
[0077] ■ The data path' and' interface resources manag- • 
■er 114 -represents the ■remainder- of the processor in:-,, 
cluding the ALU, progrannmer-visible registers and so : 
forth. All ot the I/O device, host computer (if any) and 
local data memory interfaces (channels 126,. 128, 1 30, 
1 32) connect to'this functional block. The datapath and • 
interface resources manager 114 sends' event signals , 
to the context controller 1 1 0 and receives an AckEv sig: ■ 
nal (which indicates that software has executed an ACK 
function to acknowledge a specific prior Event), CsLoad 
and CsStore signals' (to restore and to -'save context ■ 
state information), and SetCy and CtearCy signals (to 
set and clear a carry flag for use after hardware reset 
arid I NIT functions) from the context controller 110 via: 
a CctllDP ^channel 143, This functional block also ex- 
ports the values of ien (equal to true if the current clock 
cycle is an instruction execution cycle) and slice (the last 
value specified by software for the rinitial- instruction, 
count for each background time slice). 
[0078] The context controller 11 0 advantageously ac- 
cepts exogenous event signals via an Events In channel 
124, and communi(:ates with other functional blocks as 
mentioned above. This functional block also exports the 
values of Boolean variables asleep (equal to true when 
in sleep- mode) CSW (equal to true during' the second 
half of context switch cycles) and idle (equal to true 

■ when there are no active contexts), Qtxfs^urri (context 
•number)/ variables context (the running context's 

- number)", and nctx (the number of the context to which' 
execution is being switched). And, this functional block 
also exports BitString variables events (the current con- ; 
text's event status register) and rhask (the current con- 
text's event mask register value). ^- • ■ 

' [0079] Turning now to FIGURE 5, illustrated is an SDL 
process interaction diagram showing an internal struc- 
ture of the context'controller -110 illustrated ^in FIGURE . 
4. The- internal structures of the other top-level blocks 

" are not presented herein because "they are not part of 
the presehtihvention and are not required to understand 
the behavior of the context controller 110.' --^ 
[0080] Two processes are illustrated as being con- 
tained in the context'controller block 110, An event syn- 

■ ch'ronizer- 150 accepts exogenous event signals from an 
AsyncEv'enis sign'al route 15S"and synchronizes them- 
with the m^ster'clock rising-edge -Mr.517, which is pro-- 
vrded 'by the clock generator 106 via a ClkSyn signal. 

' route 156.- These events are isent on, via a SyncEvents 
signal route 166, as event signals, just as with the (in- 



herently synchronized) event signals from endogenous 
sources on a PriDP signal route 164. . . . 
- [0081] The fundamental context control .state ma- 
* chine operates in an event prioritizer process 1 52 in this 
5 embodiment. The event prioritizer 152 receives input 
-signals from the clock generator 106 via a CtkPri signal 
route 154, event signals from the event synchronizer 
150 via a SyncEvents signal route 166 and data path 
: CctlDP functions 1 43 via a PriDP signal route 1 64. Ad- 
?0 : ditionally, decode signals for various instructions rele- 
, vant to context control and inter-context communication 
from an .instruction decoder over the InstCctI channel 
142. via an InstPri signal route 162 are received. 
. [0082] . Turning now to. FIGURE 6, illustrated is a proe- 
ms ess diagram. of the event synchronization process illus- 
trated in FIGURE 5 which- depicts the operation of the 
event synchronizer 1 50. This process ensures that each 
incoming ExtEvent signal 208 is saved until the occur- 
rence of a master clock rising edge Mr 206, at which 
20 time all saved -ExtEvent signals. 214 are .received and 
imnaediately passed-to.the event prioritizer, 152 as Event 
signals;218. : - . - . : ■ . 

„.[0083] Turning now to FIGURES /A, 7B- 7C and 70, 
. collectively illustrated are process diagramsof the event 
25 prioritization process shown, in FIGIJRE 5 defining the 
-.state transitions of the event prioritizer .152. process. 
This process innplements the event driven, and time- 
sliced context switching.functions for this embodiment 
of the present invention. ■ , 

30 [0084] ' FIGURE, 7A defines the startup and reset se- 
quences. In "all states"symbol 272, a reset signal 274 
takes precedence;Over all other input signals and caus- 
es the process input -queue (symbols 276-280) to be 
flushed before joining a startup initialization (symbol 
35 282) .starting at a start symbol 254, A sequence (sym- 
bols 256-270) initializes all relevant variables, clearing 
. event masks, event status registers and wait flip-flops, 
setting all contexts to foreground, and clearing all ACT 
flip-flops, except for that of context, 7, which is forced 
-^0. active. • . . ' . 

. [0085] .FIG.URE 7B defines operation during the sec- 
vond half of each cycle, an Mf.to Mr period, (a period from 
a master clock falling edge Mf to its next rising edge Mr), 
as well as the, events immediately following the receipt 
-^5 ofra master clock rising edge Mr 292.. Running and idle 
. states 284 both have the same-transitions, since an in- 
struction is executed during the cycle following a WAIT 
function, and because events may. occur and need to 
be processed during any cycle, including^imes when the 
50 processor is idle. During the Mf-to-Mr period, all instruc- 
. tion decode signals except an ACK (Acklnst), a WAIT 
■ or a SLEEP function 300 are processed immediately. 
These three signals are saved for processing after the 
master clock rising edge Mr 292 because they must be 
.55 - .handled after all Event signals 288 have been proc- 
. essed. The instructions handled ahead of -the master 

• clock rising edge Mr 292 (that is, the signals 286, 290, 

• 294, -296, 209)., may alter information that has to be 
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saved at the master clock rising edge Mr'292 if a context 

switch occurs. • . - 

[0086] After the master clock rising edge Mr 292. on 

'cycles when ien is equal to true (one)(293). on cycles 
wheh the processor may enter 'a Sleeping state (symbol 
338) during which the processor clocks stop, and only 

-a low-frequency sleep timer operates'-until either a sleep 
timeout (a Wake signal, in symbol-"340) or a hardware 
reset occurs.' If not asleep, a time slice instruction count 

■is decremented "(symbbl 330) if a background-context is 
rurining' (symbols '326, 328). If the slice count decre>^..: 
ments to zero (symbol 332). a time slice context switch 
is initiated by advancing the round-robin curBg (current 
background context) pointer by one, modulo the number 
of contexts (symbol 334),' and the: time slice' instruction 
count is reset (symbol 335) to"its programmed value: 
Then a prioritize state 336 is entered to handle an Mr-^ 
to'Qr period' (a period from a master clock rising edge 
Mr to the next quadrature clock rising edge Qr). 
[0087] FIGURE 7C defines operation during the first 
quarter of each cycle (the-Mr-to Qr period). This is the 
time when the events sampled at the master clock rising 
edge Mr 292 are masked and the ACT flip^ldps are up- 
dated iri preparation for making a context- switching de- 
cision -after- a quadrature clock rising edge Qr 380. An 
ACK (Acklnst) signal 352. a WAIT signal 360 and a 
SLEEP'signal'366. ai-e handled prior to the quadrature 
clock rising edge Qr'380,' and a masking and ACT up- 
dating sequence (symbols -386-392) ^occurs following 

'the' quadrature clock rising edge Qr 380. 
[0088] The' updating of' ACT :bits lis depicted as an it- 
erative process (symbols-388-392) for clarity regarding 

' the operation being performed. This operation is typical- 
ly performed for all contexts in parallel. A subtle, but very 
rmpdrtaritaction-1n FIGURE 7C is the handling of a WAIT 
function 360, where the occurrence of the WAIT function 
360 is recorded. at the index of the previous (prev) con- 

' text (symbol 362) (which is the context that was running . 
prior to the master clock rising edge Mr 292 -when the 
WAIT function 360 was decoded). Then the clearing of 
:the ACT flip-flop (symbols 382-384)ls dohe 'atthe index 

' of the- current (ctx)' context. The values of- prev and ctx 

^wiil be'equal both before and after the quadrature clock 
rising 'edge Qr 380 in all cases 'except when a context 

• switch^occurred immediately precedingthe master clock 

• rising €dge Mr 292. This means that a context executing : 
aWAITfijnction on the lastcyclebefore a context switch;, 
remains active, but with its Wait flip-flop (bit in the waited : 

• bit string) being-equal to one until that. context is again 
able to run and execute the instruction followihg the 
WAIT function. Another interesting action in-FIGURE 7C 
is the sending of an'AckEv signal 356 to the Data Path 
''when an ACK function 352 is processed.' This is done 
to permit side-effects in the device or host interface logic 
to be performed when a specific event is acknowledged. 
[0089] ''FIGURE 7D defines operation during the sec- 
ond quarter of each cycle, 'a:Qr-to.^Mf period, (a period; 
from a quadrature clock rising edge Qr to the next mas- 



: - ter clockJalling edge Mf). This is, the time period when 
events are prioritized and the context switching deci- 
sions are made. The. first set- of actions (symbols 
422-428) searches for a possible preemption. The 

5 searches depicted as an iterative process for clarity re- 
garding the. operation being performed. This operation 

■ is:typically performed for. all. contexjs in parallel. If the 
. running context is in foreground, the search is over the 

range 0:ctx, wh.ereas if the running, context is in back- 
10 ground the search is over the range 0:7 because all fore- 
ground contexts: have priority-over any background con- 
. . text (symbol 423), The priority encoding (symbol 424) is 
implicit in the ascending context number 424 (descend- 
. • ing priority)}Sequence. If., an active, foreground context 
15 is found, its number is recorded in nctx (a block 452). 
' Otherwise, a search (symbols 430-434) is conducted for 
an active background context starting at the indicated 
current- background context and continuing to higher 
context-numbers (modulo 8). . 
20 , [0090] If a time slice (the symbol 334 of FIGURE 7B) 
ends at the master clock rising edge Mr 292.of this cycle, 
the indicated curBg will already have been-incremented, 
. meaning the search will start from the context after the 
one that is currently running and will only re-select the 
2S same context if no other contexts are in the queued state 
Qb: In the case of a preempted context in the back- 
; ground running state Rb that can now be resumed, this 
test' (a symbol 430) will exit immediately to a set new 
context number (nctx) 450. If.,either a foreground (set 
30 .-new context number (nctx) 452).or a background (sym- 
bol 450) search^-finds a context to run, the nctx is com- 
pared with the. current context number (ctx) (symbol 
454) to determine whether a context switch is needed. 
. If a context switch is not needed, no further context con- 
-.35 trol activities occur during this cycle and the controller 
returns to a running state 458. 

[0091 ] If a context switch is required, the controller en- 
ters Start -CSW state 456 .saviing the input signals 462 
. until a master clock falling edge Mf occurs (symbol 460). 
AO Then CSW (symbols 474-476) is asserted, and the load- 

■ ing of the saved state of the next context (a symbol 478) 
. is initiated while saving the current context state (a sym- 
bol 480) is requested.. The reason loading is requested 
before -storing isiexplained below more fully In conjunc- 

•45.-. tiom.withrFIGURES.S and 9.- 

[0092]: • If there are no active. contexts;, the controller 
saves all input signals (symbol, 440) until the master 
clock falling edge Mf occurs (syrnbol .438), then indi- 
cates>an-.ldle state 4.42, and requests saving. the current 
so context state .446 before actually .entering an. Idle state 
■_448. The context state is- saved tpecause. there is no 
guarantee thrat the same conte.xt,will be, the. first context 

, to run at the end of the idle, period. In effectrthe transition 

. ' .. to :and from. the Idle state. 448 .is.-a ,split context switch, 
55 with saving ' ^d.u ring the : transjtipri;- tp ,. id le-^ (symbols 
442-446), and loading .during .the transition from idle 
(symboIs-466-470). During the idle state, the clocks con- 
tinue tO:run and events .continue to be sarnpjed, but in- 
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structioris are neither fetched nor executed. * - 
'[0093] If the processor is implemented using complex 
mentary metal oxide semiconductor (CMOS); or anoth- 
er process technologywhere power consumption is very 
tow or essentially zei-o when the circuit elements are not 
being clocked or changing tevei. the Idle state 448 pro- 
vides an inherent' power saving mode for; most of the 
processor, including sequencer; instruction decoder and 
data path. If a still -lower power operating mode is de-' 
sired, the SLEEP function 366 (in FIGURE-TC) can stop 
th'e high-speed -ciocks, along- with- suspending event 
'monitoring, leaving only a low-frequency sleep timer in ■ 
operation. - - ' " ' ' ' 
[0094] Turning now to FIGURE illustrated'is a tim- • 
ing diagrarn for a context * switch controlled by the 
present' invention in which ai cul'reht context's state is 
stored into, ahd the next context's stat& is loaded from, 
synchronous (self-timed) SRAM or register files. The 
timing diagrams' depicted (in both FIGURES 8 and 9) 
identify the differences required to use each* of two dif- ' 
feVent types oi niemiory technology for stoi'lng the exe- 
cution states of non -running contexts.' Each of these tim- 
ing sequences has the beneficial advantage- that the 
context switch operation does not require extra cycles 
to save and restore the context execution state; but rath- 
er performs this function in parallel with execution of the 
last'instructibri of the context being switched. To employ 
this technique^ a" processor data- path should include 
dedicated register files or static RAM (SR AM)*arrays for 
each register in the execution state. The' Hfustrated em- ' 
bodimenf of the invention may be used in conjunction' 
with processor data paths that do not provide such stor- 
age. However more overhead is associated with con- 
text switching on such processors, due to possible extra 
cycles ahd an 'execution of additional instructions to 
save and restore context execution states. 
[0095] The simpler timing and control signal sequenc- 
ing, shown in FIGURE 8, is achieved when the save ar- 
rays are implemented using synchronous 'Static (seif- 
timed) RAM (SRAM). This is also the tim'ing that results 
from a direct implemehtation'based on the SDL process 
defined in FIGURE 7. Although programmer-visible be- 
' havior is identical, great er complex ity-is^' required to use^ 
asynchronous static RAM for the save arrays (as will be 
discussed in conjunction with FlGURE 9). -Ari approach 
using synchronous SRAM permits shorter' cycle times 
and lower power consumption due to a reduced number 
of signal'transltions and an elimination of controt signal 
duty cycles shorter than 50% of the instruction cycle 
time, assuming identical performance of the synchro- 
" nous SRAM and asynchronous SRAM devices. 
[00^6]" The synchronous SRAM captures the write ad- 
dress and data at a leading edge of each write enable' 
pulse, and completes the write operation using internally 
generated e'ontrbl signals, without need for stable input 
signals (other than power) during the remainder of the' 
;write cycte. Cell-based, semi-custorri integrated circuits 
' employing synchronous SRAM that use' re'gister file 



• cells- with both a read port and a write port having inde- 
pendent addresses are -.readily available. The control 

■ signal timing for a context switch becomes relatively 
. simple when using these synchronous SRAM ceils to 

s implement the save arrays, as shown in FIGURE 8. 
[0097] • During each instruction execute cycle 500, 502 

■ a context controller 514 samples .activation event sig- 
. nals at a master^clock rising edge Mr 517 allowing the 

first quarter of:the cycle. for settling and. gating of the 
10 . synchronized signals (time interval 532): At a quadra- 
. ture clock rising edge Qr-518, all .ACTflip-flops are up- 
' dated and the priority encoding and comparison opera- 
tions determine the need for a context switch, selecting 
a next context if required (timeiinterval 533). In parallel 
15 with these context controller activities, a processor (time 
interval 516) has been executing an instruction initiated 

■ at the master clock rising edge Mr 51.7; without regard 
: for whether a context switch may be necessary during 

• this instruction execution cycle. I:f:a processor data path 
20 has combinatorial paths from internal register sources 

that are expected to be stable throughout the-.execution 
cycle, valueson these paths must be latched at a master 
clock falling edge Mf 519 to permit readout oj a saved 
^ state of a next context to begin .(time interval 540). Al- 
25.. ternately, if a processor designer prefers to add over- 

■ head cycles for reading a saved context state, this latch- 
ing is not required. But, in most cases, one or more cy- 

' cles are inserted and a nel'effect will be a.slowdown of 
processing and real-time response if- these latches are 
30 eliminated, resulting in a period when instructions can- 
not be executed between a last instruction cycle of an 

• old' context and a first instruction cycle of a new context. 
. [0098] At the master clock falling edge Mf 519, the 

■ context controller can determine, whether a context 
35 switch is. required (time interval 534), -and assert an 

CSW signal-522 if so. The target state to be restored is 
indicated by placing a context number of. a next context 
on a NCTX[2:0] signal group 530. This starts a "saved 
. State" readout of a next context (time interval 540) using 
40 a NGTX[2:0] signal group 512 to address the- save ar- 
■■ rays- in -parallel. with a completion of the last instruction 

• of 'the current context (whose context number remains 
on.a GTX[2:0] signal group 5-24). . : 

[0099] At'the end of this context switch. cycle 6es\g- 
^5 nated by; the master clock rising edge Mr 51 7 (separat- 
' ing cycle 500. from cycle 502), an execution state of a 
curYent context, including an outcome generated during 
this execution cycle 500, Js stored (time interval 542) 
- using a CTX.[2:0] signal group 510 to address the save 
50 arrays. The save array write operation (a time 542) is 
initiated by the master clock rising edge Mr 51 7 when a 
CSW signal 508 is asserted (time interval 522). Due to 

■ the'advantageous characteristics of writing to synchro- 
.nous:SRAM, a first instruction of the next: context can 

55 commence, execution immediately (time interval 536), 
since neither the address nor-data being written to the 
save array, has to be. held after the master clock rising 
edge Mr 5-17 occurs,- which ends cycle 500. For proper 
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execution: the synchronous SRAM cycle tin^e. including 
write recovery, may hot exceed 50% of an: instruction ■-' 
cyc'l-e period. The same master clock nsing.edge Mr 51 7 
transition that initiates an 'SRAM write may also be ad- 
vantageously employed to complete, a. 'context switch- 
with' a CSW signal 508 negated and a CTX (2 0] signal 
group SlO updated to a new context number 526. 
[0100]' " Turning- how 'to FIGURE-9. illustrated is a tim^ 
ing diagram for a context switch ; controlled by the , 
present-invention in^which the current context's state is 

■ stored into, and the next -context's state is loaded from, < 
asynchronous SRAM or register files" Conventional, on 
asynchronous, SRAM requires that a^write address and 
data be stable throughout a relevant portion of a write 
cycle. This nece'ssitates a setup time prior to a trailing 

■'edge of a write enable pulse and sometimes requires a 
short hold time following this trailing edge. Many semi- 
custom- integrated circuit technologies can supply RAM 
arrays-or register files'using asynchronous .SRAM that 

' provides a single address and data port which may be 
used- for e'ither reading or writing: Separate SRAM and 
register file chips that operate imthis^manner are also 
widely'avatlable. 

[0101] To use this type, of conventional, single-port 
SRAM'to implement the save arrays, control signal tim- 
ing for a context switch^ becomes somewhat more com- 
plicated, as shown in FIGURE 9. General timing is the ^ 

- same^as in FIGURE 8, and similar elements. are identi- 
fied using the- same reference numbers. A primary dif-- 
ference is the generation of the.NCTX[2:0] ^signal group 
512, in operations by context controller 514, and a data 
path 516 during and immediately after an assertion of a 
CSW signal 548 (as detailed in times 528;, 530, 534, 535: 
537,' 540, 541, 543 of -FIGURE 9). 1t is necessary to use 
asynchronous SRAM with a cycle time does not exceed 
'25%-dt the instruction cycle penod. including, write re- 
covery in-order to avoid insertion of overhead cycles,^ 

'assuming no instructions are executed while saving and 
restoring a context state. This speed, requirement is 
twice as fast as that needed to achieve the same proc- 
essor cycle rate when using synchronous SRAM. The 
context switch activitiesare identical during the first half; 
of the context switch cycle (time intervals 532, 533, 538). 
At a master clock falling edge Mf-51 9j'.<!)f Uhe context 
switch cycle; a CSW signal. 508 is.^asserted (time inter- 
val. 522) and a NC.TX[2;0] signal group 51 2,is set to the 
next context' number (time interval: 534). Address and 
:data information must be stable while writing the results 
of the last instruction executed by the current context^ 
into the save arrays. Therefore,, only a period from the 
master clock falling, edge Mt 51 9 to the,next quadrature 
clock falling edge Qf 520 is available.for readout of the 
saved state for the next context (a time 540). This out- 
come is then preferably latched.andiheld during a period 
from the quadrature clock falling edge Qf 520 to the next 

"master clock rising edge Mr 517..^ Then, these latched; 

■ values are advantagisously. transferred to the proces- 
sor's working registers (time interval 543).- At the quad- 



rature-clock falling edge Qf 520, the value of the NCTX 
. [2:0) signal:group 512 switches back to the current con- 
text number (time interval 535), allowing the current con- 
text state,, including results of this instruction (cycle 500) 

5 to b,e written to the save arrays (time interval 541). At 
the master clock rising edge Mr 51 7, the NCTX[2;0] sig- 
nal group 51 2 switches back.to the next context number 
(tjme interval 530) and execution of a first instruction of 
, the next, context begins (time interval 537). 

,10: ,[0102] Unlike the synchronous.' SRAM implementa- 
, tion, the write operation is completed at the. master clock 

:■ ; rising edge Mr 51 7.- Use of the asynchronous SRAM re- 
quires that the data path results be stable relatively early 

, . ' to allow writing to the save arrays during.-the, interval 

IS -, from- the quadrature clock falling edge Qf 520 to the 
master c!ock.rising.edgaMr517. Whereas with.synchro- 
■nous SRAM, the data path results are not needed until 
just prior.to the master clock rising edge Mr 517, which 
facilitates shorter instruction cycles and therefore faster 

20 processing. , . . , ^ 

[0103], Turning now to FIGURE 10, jllustrated is a 
schematic diagram of one embodiment of a circuit suit- 
' able for implementing event recording, event masking 
and. event acknowledgment for each activation event, 

■ 25 as well as management of a context activity bjt, including 

initialization request and wait request logic^where the 
details of .event recording, masking and acknowledg- 
ment within, the context cpritroller may better be under- 
stood. , . ' ^ . , - 

30 [0104]- A generalized schematic fragment of a "slice" 
of a context controller event. logic is presented for a sin- 
gle event includirig an ACT bit and WAIT function logic 
of the cont^ext. associated- with that event. In this dia- 
... gram, alljogic signals are considered tp be asserted in 

35 the "high " true (logical one) state. This schematic frag- 
ment is illustrative of an embodiment, of the event logic 
and is not nneant to be a limitation on practice of the 
present/invention. 
/ [01 05] An exogenous event signal 550 may be assert- 

.^0, ed with either polarity, so a programmable inversion 
function 560, under control of a software signal 551 may 
; be provided to establish a high-true signal fpr internal 
cuse..: Because. this exogenous signal has an undeter- 
mjned phase relationship.with the internal clocks, a syn- 
, chronizer 562:that synchronizes the input signal with a 

■ ■ , , master clock rising edge Mr 5 17 . prior to its internal use 

is employed.; A plurality of sources. may be used to set 
an event flip-flop 570 including a leading edge of a syn- 
, - chirpnized external signal 564, a leading edge of an in- 
50 ternaj source 566, or a software ^SlGNAL function 552 
.^which designates this context and event. These event 
, . ■ .sources are, combined by an OR gate 56,^. w^ipse output 
...enables ari. event flip.:ftop..570, to tpe set_at the master 
:clock rising edge Mr 517. ■ .- v.-k 

■ -^^ ' ,[0.106] Because, the.event flip-flop P.-J,r}.put,570 is hard- 

wired ..true (tp a. logical, one .as shown), .qegation of an 
event signal after setting the event fliprflop.57p does not 
rescind the event. The event f. I ip.-flop output 570 may be 
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read by software as a. bit in the event status register 9.4 
and as a testable condition in an events condition signal ' ' 
group 596 if the processor provides instructions such as 
the SKPn of the itlustrated embodiment (as^ described 
below); The event liip-flop 570 can be cleared either by 5 
a hardware reset 555 or^an AND gate 572 output, whose 
ANDed inputs incorporate the execution of an' ACK (ac- 
knowledge) function 554 for this event number while this ' 
context is running (a signal 556), applied through an OR * ■ 
gate 574. - ' - =- ' ■- io 

[0107] An Appropriate bit for thfs context event from ..■ 
the context's'event mask register 94= event mask bit 558 
is ANDed in an AND gate. 580 with an event flip-flop . 
output 570 and applied to the-input of aniACT flip-flop*. ■ 
590^through ah- OR gate 584. The output of. this AND ^5 
gate 580 is also used when performing priority encoding 
of the context^ events for the VECTOR function, as is 
described in greater detail below. A masked event signal 
from the AND gate 580 is ORed in the OR gate 584 with 
the masked event signals from all other events associ- 20 
ated with' this context including a signal from the output, 
■gate' of 'the" wait logic through an AND gate 582. 

' [0108]- A logical true output condition of the OR gate- 
584 enables the ACTflip-flop 590. allowing the ACT flip- 
flop 590 'to b'e set to the output value of a NOT inverter - 25 
586 at the quadrature clock rising edgeOr 518. By using 

- the output of -the AND gate 582 and an inversion of the 
same signal through the NOT inverter 586. the Act flip- 
flop 590 D-input may be enabled. The ACT.flip-flop 590 
is set at the quadrature clock rising edge Or 518 if one 
or more activation events are asserted/ and no WAIT 
function was executed during the preceding instruction 
cycle. The ACT ftip-flop 590 may also be set'directly by 
execution of an I NIT function 588 to this context, and 
cleared directly by-a hardware reset- signal- 555. The 35 
ACT flip-flop output 590 is also used by the context pri- . 
ority logic and is inverted'by a NOT inverter 592 to clear 
a WAIT- flip-flop 578. The ACT flip-flop 590 is cleared' . 
through the NOT inverter 586 if a' WAIT function was 
executed during the preceding instruction cycle whether -40 
or not any activation events are assorted. 
[0109] The WAIT flip-flop 578 is n^ded because a • 
context may be preempted between executing a WAIT- " 
function' and executing an. instruction 'Which follows the 
WAIT function. (An example of this occurrence is shown 
at 53,-54 and 58 of FIGURE 2).-When a WAIT function. 
557 is decoded by an AND gate 576 while this context 
is running (a signal 556), the~WAIT fliiD-flop.578 is ena- 
bled to set at the master clock rising edge-Mr 51 7. Be- 
cause a context must be active to execute a' WAIT tunc- mo- 
tion, thiis action records the occurrence of'the WAIT 
■function since the output of the ACT flip-flop 590 being • 
in the true state negates the clear input of the WAIT flip- 
flop 578 through the NOT inverter 592. 
[0110] At the next quadrature clock rising edge Or 55 
518, in which this context is a running-state (the signal . 
556). the ACT flip-flop 590 is cleared due to assertion c 

' of the" AND gate output 582; If this context is preempted . 



.or time-stieed at the same instruction cycle boundary 
(the master clock rising edge Mr 51 7) that the WAIT flip- 
flop 578 is set, the, context will not be running. Hence, 
. the context running signal 556 will be negated prior to 
■ the next quadrature rising edge Or 518, and the ACT 
flip-flop 590 will remain set. When this context resumes 
running, the ACT flip-flop 590 will be cleared at the quad- 
rature clock rising edge Qr 518 of the first instruction 
cycle causing the context to. become, inactive after exe- 
cuting this one instruction. The negation of the ACT flip- 
flop output 590 clears the WAIT flip-flop 578 via the NOT 
inverter 592. • 

[0111] .Turning now. to FIGURE 11, illustrated are field 
and bit assignments of machine instructions pertaining 
to context control and inter-context communication in 
the instruction set according to one embodiment of the 
present; invention. ^ The details of the instruction decod- 
ing and field encoding are not directly relevant to the 
present invention;; and this figure is included primarily to 
illustrate the-'operand fields that provide information 
needed .by the context controller.' ^ , 
[0112] ' Testing of bits in=the context event status reg- 
ister 94 is most efficiently accomplished using SKPx in- 
structions 600. These instruct^ons perform^a test under 
mask or bitwise comparison between a .specified "con- 
dition group" (C-group) 604 of eight related signals and 
an eight-bit mask value 605 contained in the jnstruction 
word. If the condition. specified by a test operation 603 
is true, the instruction following, the SKPx is skipped. 
Relevant^ to the present invention, is C-group 01, an 
"EVENTS" group 608 which .is unaffected by the event 
' mask and which tests the contents of the event status 
register 94 of the running context.- • 
[0113] A VECTOR instruction 610 is decoded from the 
same opcode. 602 as the SKPx instructions but has a 
distinctive value in its "test operation" field 6.1 2. The oth- 
er 10 bits of the VECTOR instruction word are a vector 
base address 613 whose use is described below. 
[011 4] A SIGNAL instruction 620 is used to implement 
an .inter-context software signaling function previously 
described/The SIGNAL instruction 620 is one of the 
vprocessorcontrol instructions based on the value of an 
extended opcode field 622 with a distinctive subdecode 
value 623.- Two parameter fields are decoded within the 
context controller when a SIGNAL instruction is execut- 
ed.'.A specified event number 624 identifies a particular 
event to assert among the' events associated with a 
specified context number 625. All events may be the tar- 
get of the SIGNAL instruction 620. but implementation 
details in particular instances of this context. controller 
and connected event sources may make it difficult to al- 
low the SIGNAL- instruction- 620 to assert certain condi- 
tions. 

[0115] ■ An ACK instruction 630 and an INIT instruction 
. 640 are formatted and decoded in a similar way to the 
SIGNAL instruction 620 but have only one parameter 
field each. The ACK instruction.. 630 carries only an 
event number 624, because acknowledgment of a con- 
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text's events is only pernnitteci'by code executing in the- 
sanne context, so a context- number paranneter would be 
superfluoLis. An INIT instructibn 640 carries, only a con- ■ 

• text nunnber 625 because'the initialize function is direct- 
ed to a context, not:td an event associated, with a con- 
text. ' - ' ■ •■ 

[0116]' A STROBE instructibn ' 650 can; generate a 
specified one out of as nnany as 32 discrete, imperative 
control functions 653. A WAIT instruction 654, is of rel- " 
evance to the context controller' which:clears the ACT 
bit of the running"' context: a SETFG instruction 655,. 
which sets the FG bit of the running context; a CLRFG ■ 
instruction 656, which clears the FG bif of the running 
context; and a SLEEP instruction 657, which causes the 
•context controller to suspend operation and to allow the. 
processor to enter an extremely low-power sleep mode. - 

■ [0117]' The INIT instruction 640 is used to force the - 

• target context into a known state either for initialization 
or for -error recovery. Execution of the INIT instruction 
640 sets both the' ACT and' FG -bits to be logically true 
in the context specified in the instruction. It also sets. a., 
context CY (carry) flag to allow contexts to distinguish 
between hardware reset (when CYis equal to zero) and • 
INIT (when CY is equal to one) and forces the context 
to begin executing at a context-spec ificinitialization vec- 
'tor.'"^ ' ' ■ 

[0118]' Turning now to- FIGURE '12. illustrated are 
sources of bits used to generate control store addresses 
on the processor according to one embodiment of the 
invention. The initialization vector address for a context- • 
specific -initialization vector mentioned above, may be. 
formed by placing the contents of a context number field 
625 of the INIT instruction 640.(of FIGURE 11) into bit 
Ibcatidhs five through three of an address, word contain- 
ing all zeros as seen in an entry for an INIT Instruction 
666 shown in FIGURE .12.- 

[01 1 9] ■ Turning now to FIGURE 1 3, illustrated is an ex- 
' emplary data structure diagram for initialization vectors 
in control- store according., to one embodiment of the 

'pr'esiBnt invention. As shown, this embodiment uses-a 
set of eight initialization vectors 670-677 located at suc- 

'cessive four-word intervals, control store address pat- 

•' tem678starting'atcdntrol store address 0x0000. A four-/ 
' word vector pitch, was chosen because: a. long, absolute 
branch on this' processor requires three words, and all - 

- but' the last (context 7) vector 677 are likely to require 
such a branch. Requiring no branch for. context 7 is use- 
ful because context 7 is the'sotexonlext to be active 
after hardware reset. - ' ^ 

[0120] ' Therefore, the code at^the context 7 initializa- 
tion vector is used to initialize the. other contexts after 

• hardware reseit and for handling an INIT function to con-- 
text 7. The vector pitch for use on other p.rocessors can 
be chosen in an embodirnent-dependenti manner It is 

■ also desirable on some processors to use the contents 
of -the initialization vector as an address which performs 
an indirect^branch through the vector-rather than start-, 
ing program execution at-the'veetor address.. The VEC--: 



. TOR instruction 610/ shown in FIGURE .11., is useful for 
priority-based decoding of .the event(s) causing context 
. activation., ^ . 

[0121]. . Turning now to FIGURE 14, illustrated is a di- 
s agram setting forth target address generation by vector 
instruction used to prioritize.and decode specific context 
activation bits on the processor according to one em- 
. bodiment of the present.invention. As stated earlier, the 
VECTOR instruction 610. is useful for priority:based de- 
yo coding of the event(s) causing context activation. When 
executed, this instruction branches.^to one of a set of 
•eight handlers 680-687 in a vector table:.69p located in 
control store. ' - / 

{01 22] ' A vector table base address 61 3 is specified in 
■75 the ten lowest-order bits of. the VECTOFl instruction 
: word 610. A sp.ecific vector is selected by priority encod- 
ing the context event status register 94 ANDe.d with the 
context event mask register 90. Then, using a resulting 
. event number:694"as bit positions six through four along 
20 with a set of zeros 692 in bit positions three through zero 
■■ of the vector address 678 (as seen in FIGURE. 13) caus- 
es execution to continue at the beginning of the eight- 
word handler. location ,680-687 assignedlo the highest- 
priority (lowest-numbered) asserted non-masked event. 
25' Because the VECTOR instruction 610 shown in FIG- 
•' URE^II is normally used shortly after reactivation fol- 
: lowing a WAIT instruction 654, there is reason to expect 
that at least one non-masked event fljpjftop will be true 
(equal to one). If this were not. the case, the context 
• 30 wouldrnot have become active. However it is possible 
• to include a-vector at Base-i-64 words 688 for the case 
where no. event bits are set. . , 
[0123.]" For the instruction set of the .current embodi- 
ment, this vector pitch of eight words permits many han- 
35 ' diers to fit entirely 'within the vector table requiring no 
branch .while handling that event. For embodiments 
which provide a vector decode function of this type, the 
pitch-may be chosen to achieve a balance between fit- 

■ ting the entire handler set into the vector table and leav- 
40^ .jng substantial amounts of cor^trol store unused due to 

the handler areas being much longer than is generally 
required. ^. . . ^ . ' ) . 

: [0124]'. From the above, it is apparent that the present 
■ invention:: provides a. context controller for managing 
- ^5 multitasking in a processor and a method of-operating 
. the same. I,n one embodiment,. the context controller in- 
: cludes;v(1 ): foreground and background task controllers 
."that;allQcate pi'ocessor resources to active contexts cor- 
responding: to foreground- and background tasks, re- 
SQ : spectively, and, (2) mode switching ci/cuitry, coupled to 
rthe foreground and background task, controllers, that 
' ' •- ■ places the processor-in.an:idle.state,and-a power saving 
' mode when all of the eontextS:are Jnactive. . 

■ Claims. . . -.i , -\ "■ ;;•■:.■ 
1, ■ A context controller for managing.nnul.titasking in a 
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processor, comprising: 

foreground and background task controllers 
that allocate processor resources to active con- 
texts corresponding to foreground and back- 
ground tasks, respectively: and 
nnode switching circuitry, coupled to said fore- 
ground and background task controllers, that 
places said processor in an idle state and a 
power saving mode when all of said contexts 
"are inactive. 

The context co'ntroller as recited in claim I wherein 
a software switch, state "distinguishes said fore- 
ground tasks Irprn said background tasks. 

The context controller as recited in claim 1 or claim 
2 wherein said foreground and background task 
controllers allocate said processor "resources- only^ 
to said active contexts. 

The context controller^as recited iri any of the pre- 
ceding claims wherein said background task con- 
troller activates 'said contexts corre'sponding to 
background tasks based on numbers of instructions 
executed by each of said background^tasks. 

the context controller as respited in any of the pre- 
ceding claims wherein' said contexts are stored in 
separate register sets. 

The contextiontroll^'r as- recited in any of the pre^ 
ceding claims wherein said foreground task control-* 
ler that activates contexts corresponding to fore- 
ground tasks based on priority and in response to 
- events and said background task controller cycfcly 
activates contexts corresponding to backgroiind 
tasks subject ^to activation of said contexts corre- 
sponding to said foreground tasks. ? 

The context controller as recited in any of the^pre- 
ceding claims wherein said fore^ground task control- 
ler is adapted to activate a conTe)rf c;6rr6spohding 
to a particular foreground task by vectoring to a soft- 
ware-selectable memory location. 

A method of managing multitasking in a processor 
comprising the steps of: 

allocating processor resources to active con- 
texts corresponding to foreground and back- 
ground tasks, respectively; and 
placing said processor in an idle state and a 
power saving mode when all of said contexts 
are inactive. 
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from said background tasks. 

1 0. The method as recited in claim 8 or claim 9 wherein 
said foreground and background task controllers al- 
locate said processor resources only to said active 
contexts. 

11. The method as recited in any of claims 8 to 10 
wherein said background task controller activates 
said contexts corresponding to background tasks 
based on numbers of instructions executed by each 
of said background tasks. 

f2. The method as recited in any of claims 8 to 11 
' * wherein said contexts are stored in separate regis- 
* ter sets. - 

13. The method as recited in any of claims 8 to 12 
wherein said foreground task controller that acti- 
vates contexts corresponding to foreground tasks' 
based on priority dnd in response to events and said 
•backgrounri- t4sk controller cyclicly activates con- 
texts corresponding to background tasks subject to 

. activation of said contexts corresponding to said 
foreground tasks. 

14. The method as recited in any of claims 8 to 13 
wherein said foret^round task controller is adapted 
to activate a context corresponding to a particular 
foreground task by vectoring to a'software-selecta- 
ble memory location: 

15. A processor, comprising: 

an instruction decoder that decodes instruc- 
tions received into said processor and corre- 
sponding to a plurality of tasks; 
a plurality of register sets, corresponding to 
said.plurality of tasks, that contain operands to 
be manipulated; 

an execution core, coupled to said instruction 
decoder and said plurality of register sets, that 
executes instructions corresponding to an ac- 
tive one of said plurality of tasks to manipulate 
ones of said operands; and 
, a context coritroller as claimed in any of claims 
i to 7, coupled to said instruction decoder and 
said execution core, that manages multitasking 
with respect to said plurality of tasks. 

16. The processor as recited in claim 15 wherein said 
processor forms a portion of a general-purpose 
computer 
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The method as recited in claim 8 wherein a software 
switch state distinguishes said foreground tasks 
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FIG. 4A 



system IO_Controller 1 00 



j} BitSlringS 4 16 based on BiLString Jrom Z.105 
syntyjpe Cgroup = Integer constants 0:3 endsyntype; 
syntype Cond = Integer constants 0:31 endsyntype; 
syntype.CtxNum = Integer constants 0:7 endsyntype; 
syntype EvehtNunri = integer constants 0:7, endsyntype 
syntype InstAddr - Irleger con^tants 0:65535 endsyntype; 
syntype Instruction = BitString15 endsyntype ; 
syntype Offset = Integer constants -128:127 endsyntype;' 
syntype Vbdse,;= Integer constants 0:1023:, endsyntype; 
. /♦ ixported^from Context^Cbntroller ♦/ . 
remote asieep/ csw, idje Jobleon. nodelay ; , 
remote context CtxNum nodelay" ; /• runnmg context V 
remote' events BitStfing8 nodelay ; /* C-group 01 V ^ 
remote "^ncfi XtxNum nodelay ; next context •/ 
remote' mask BitStringS nodelay ; Event Mosk reg V" 

/•. Exported from Doto_Path_and_Interface_Resources ♦/ 
remote slice Nqlurol nodeloy ; /♦ inst cycles per bg slice •/ 
remote' ien Boolean nodelay ;"/♦ true for execute cycles */ 



signal » ^ ; 
AckEY(CtxNum,EventNum). 
AclcInst(EventNum). 
acInst{Cond,Offset), CleorCylCtxNum), 
CleorfG, CSoddr(InsUddr). : 
CSdatfl(Instruction), 'CsLoad{CtxNum), 
CsStore(CtxNum), 

E^rit(CtxNum,EventNum), ^ ,.: j - 
E?L£v€nt(CtxNuni,^^^ WOscj 
HwReset IniUnst(CtxNum). ^ j 
InitSeq{CtxNum), LfOsc, ' 
LoadMask(BitString8), M^ Mf. " ; 
Qr, Qf, Reset, SetCy(CtxNum), \ 
SetFG; Sig.nalInst(CtxNum,EyentNum), 
Skplnsl(Cgroup.BitString8), . Sleep, 
VecInst(Vbcse). Wail. Woke ; 
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ClkCcU 
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block ContexLCoritroller ' ;".isie"ep] 

no' 



:; 'it r~ 



154 

Clk'Pri 



141 

/ 

CctlSeq 



CsLond, 
CsStore. 
InltSeq 




1(1) 



. I 



150- 



EvenLSvnchronizer 
(1.1) 



158 
AsyncEvents 



.(ExtEvent] 



124 

/ 
Eventsin 



142 
InstCctI 




Acklnst, 
CleorfG, 
Initlnst, 
Loadwldsk, 
Self G. 
Signallnst, 
Sleep, Wait 



[Event] 



164 

PriDP., : 



AckEv, 
ClearCy, 
CsLodd, 
CsStore, 
l^etCy 



CcUDP 

\ 
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process Event. Synchronizer 1 50 



1(0 



> signal EndUark, ResetMork ; |\ 
signalset EndMoric, ExlEvent, 
Mr, Reset, ReselMarfc ; 

del cjl CtxNum ;v • ■ 
del e| EventNum ; 




201- 



204 — (Hold_Events 



212^ Pass_Events 



-ExtEvent 



218- 



Event 



This process synchronizes eivents originating outside of 
the DISC' core to the leoding edge of The assertion of 
each external event is indicated bf an ^ExtEvent signal. The 
parameters of the signol provide the target context ond 
event numbers. 

[xtEvent signals are saved in the process' input queue 
until receipt of signal Mr from the CIocLGenerotor block. 
The end of the input queue is morked and all ExtCvent 
signals queued oheod of the EndUork are copied to Event 
signals and sent to the Event^Priaritlzer process, where 
they are hondled ot the next Mr. •/ 




' EndMork 



Ho!d_Events 



'216 




^ Reset 



I 



/ ReseUJork 
\ to self ' 



-224 



-225 



■228 




Hold_Events 234 



'222^/ 
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process EvenLPrioritizer 1 52 



del act BitSlringS ; [N^ 
del c|, curSg CtxNum ; 
del €| EventNum ; 
del evMask, evStotus 

Array(ClxNum, BitStringS) 
del fg BitStringS ; 
del k, I, prev CtxNum ; 
del siiceCount Natural ; 
del val BitStringS ; = 
del waited BilStringB ; 
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signal ResetMark ; [\ 

signalset 
Acklnst, CleorfG. 
Event, Initlnst, 
LoadUask, 
Mr, Uf. Qr. Reset, 
ResetMark, SetFG, 
Signollnst, Sleep, 
Woit. Woke ; - 



1(4) 
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imported ien Sooiedh ; 
impprted. slice Naiural 



del exported asleep, csw, idle Boolean ; 
del exported ctx os context CtxNum r 
del exported events, mask BitStnngS ; 
del exported nctx CtxNum ; 



'252 



This process hondles signals that alter event state, 
context activation state, or execution state (sleep^ idle). 

While Running, events, Signal Instructions, and loading the 
Event Mask are hondled at once; while Ack, Init, Sleep, 

Wait, and Set/Clear FG ore held on the process -input 

queue until Ur. At Mr of execute (ien=1) cycles, any ;\ 
queued instruction (max=l /cycle)! is processed, the ,context 
number, event flags (C -group l) and event mask volues 
are updated to reflect a possible context svitch, an^' the 
slice count is decremented if the njnning context is in - 
background. At Or the octivity flags are updated^, then* the 
highest priority active (fg) context, or current/next (bg) 
context is selected for execution at the next Mr, 
performing a context switch or going idle, starting -iat-Mf, 
as appropriate. •/ ... . 
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act 


:= 0x80; 


256^ 


ctx 


:= 7. 




<g • 


= OxFF, 





events 


:= 0x00, 


258-^ 


waited 


:= 0x00, 




mask 


:= OxOO. 



260- 



262 



264 



cuffig :.= ;0, ■ ' 
sliceCount := r 
import(slice) 

HZ 




InitSeq{7) 




C!8fl,|Cy(7) : 



266- 



export , 
asleep, csw, 
ctx; events; 



FROM nC. 7A1 

A - 




asleep 


:= false, 


csw := 


false, - 


idle := 


false 





-257 



evMask(0,1,2, - 
3.4.5.6.7) ^ ' 
:= 0x00, ,> 

evStatus(0,1.2. 
3.4.5,6.7). 
:= OxOb • 
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Cstfiad(7).;3j 
,yio,,PriS 



272 







Reset 






/ ?esetMar1( 
\ to Self 
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Flush.Signals p--278 



^ResetMork 
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Running. 
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process -Event_Prioriti2er-^i52 



3(4) 



Prioriti ze \ ' J ~^i5Q 



Acklnst 
(el 



"^352 



36b 



Wait 



1 



(evStatus(prev)) 
(e|) :=0 



Qr 



^380 



362 
^354 



Ack£v 
(prev. ejjl) 



364 



*aited(prev):= ' 



p— ( waited{ctx) 



(=0) 



(=1) 



■382 



>35b : 



•358 



act(ctx) := 0, 
waitBd(clx) := 0 X384 



;586 




oct(c# := 
if (evMask(cji!) 
and 



^388 
else 



evStat.us(ci)[)). = 0 
then act{c|) 
else 1 ifi 



389 



(=7) 



•390 



366s^> Sleep 



368- 



370- 



asleep := true 



I 



export asleep 



372- 



374. 



I 



Sleep 
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process Event^Prtoritizer 

/ 

152 









nctx := 


curBg, 


-• !("-:= - It •+■1 




k := 0-, 
1 := if 
















/ fg(k) and V 




(act(ctx)=0) or 
fg(ctx)=0) theft- 
^ 7 else ctx fi 
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(true) 



k.<. 1 



(false) 



(false) 







curSg : 
(curB^ 
mod i 


1) 






cijr8g=nctx ^ 




(true) 




Idle J 



not(fg(curB9)) 



428 



-430 



(=Q) \ ond Qct(curB9) / (=t) 
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-450- 



nctx :=. curBg 
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Mf 



438 



77 

440. 



T 
m 



452 . 



nctx •:= k 



ctx = 
nctx 



(false) 



Stort_CSW 



Mf 
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FROM HG. 701 

A 



f r. 



0 



CsSdve(ctx) 
via oil 
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(true) 



idle 



GsLoad 
(nctx) 
via all 



-470 



(false) 



{nctx) 

■ via'^all- 



idle := 
csw 1= 


t'ue, ; 
true 




idle := 
csw := 


false, 
true 


—466 


csw ;= 


true 


•^474 




















export idle, csw 




export i8le, csw 




export csw 


---476 
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Running 
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CsSove 
(ctx) 
via all 
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Ini|alization Vectors 




CS Word 
Addr 


570-^ 


Context 0 Initialization Vector 




oooa 


671-^ 


Context 1 Initialization Vector 




0004v 
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Context 2 Initialization Vector 




0008 
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Context 3 Initialization Vector 




OOOC:: 
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Context 4 Initialization Vector 




0010 


675-^ 


Context 5 Initialization Vector 




0014 
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Context 6 Initialization Vector 




0018 
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Context 7 Initialization Vector 
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